上篇文章中，我提出了一個「規畫系統」，其系統的起始點，是由 PO 與 Designer 組成的子系統。我見過大部分的 Product Owner 通常還身兼 Project Manager，或是 Job Manager，從接收需求開始，到協調設計師出 UI/UX 規格，到開發階段的任務分派與進度追踨，全包了。我一方面對這個角色充滿敬佩，一方面也在大部分的 Product Owner 身上觀察到了強大的內部張力，可以說是整個團隊中，張力-舒緩系統運作的最頻繁的角色。

"PO 的任務，是讓產品賺錢。"

而身為團隊系統架構師的職責，就是幫助 PO 回歸本務：產品設計、用戶研究與數據追蹤。與 PO 取得共識是整個系統的成敗關鍵，因為扛著營收的壓力，在無法完全掌握團隊狀態的情況下，PO 會極度的缺乏安全感。而唯有 PO 信任團隊，才能真正的建立安全感。

我幫助團隊與 PO 建立互信的過程與策略如下：

1. 溝通目標
承諾 PO 建立一個可以量化的觀測專案進度的開發系統，觀測的方式不再需要透過口頭詢問，而是由團隊主動提供資訊。PO 可以最大程度的控管風險。在雙方的協作下，PO 的日常工作負擔可以大幅度的減輕。

2. 梳理 Product Backlog

在到達目標前，PO 必須提供的協助為：

• 良好結構的 Product Backlog
  待辦清單中的任務有明確的階層結構，如 Epics → Stories，再由 RD 負責將規模較大的 Story ，拆分成顆粒 度較小的 Tasks； 結合估點系統的運作，PO 可以很輕易的掌握每個 Epic / Story 需要的開發資源(時間與人 力) 。以往，產品甘特圖可能來自 PO 的經驗估算，爾後是一個具有信心度的估算結果。
• 針對商業價值對 Backlog 進行排序
  確保開發團隊在進行當下最重要的開發工作，任何插件的原則都必須先進行價值判斷
• 明確的驗收條件

3. 改善估點系統
估點是一門學問。我常聽到 Scrum 團隊成員提到自家最秏時的活動就是估點，不僅效率差，參考價值也低。原因在於常見的「撲克估點法」「Fibonacci 估點」等實踐方式，帶給團隊很大的內部張力，如討論時間太長、不同領域的開發者互相投點、點數如何時時間掛勾等因素。因此，我介紹了一種變型的估點系統。讓 PO 了解，這次不同。
有關我提出的估點系統，之後會有專文介紹。

4. 建立進度回報機制
在每日的站立會議，PO 可以不用再詢問推進進度，讓團隊專注在「遇到的問題」「需要的協助」等重要事項。而所謂的進度回報，則是透過培養團隊每日更新點數的習慣，由專案管理工具獲取資訊。
這裡的重點不是工具，而是培養團隊的習慣。資訊流不應透過任何一個「人」當作結點，而是應該創造一個結構，讓它自然流動。但是當團隊規模較大時，例如我帶過 20 人的 Scrum 團隊 (完全違反了 Scrum Guide 的精神)，工具也確實會帶來效率的提升。
有關我如何透過設計 Scrum 工具，來優化這個龐大團隊的經驗，留待之後的文章再來聊。

5. 輔導轉型期
此時的 PO 一定處在將信將疑的狀況，經驗帶來信念，只有讓團隊有了好的經驗，接下來的系統化運作才能順暢。因此，規畫好的步驟與執行，在初期需要 Scrum Master 跟緊一些。例如，承諾讓 PO 會拿到的資訊， Scrum Master 必須使命必達，即使團隊還沒完成養成習慣，也必須想辦法提供。讓 PO 的訊息流簡化到單一窗口，再逐步進化到由團隊主動提供。

PO 系統的修正，可以說是一個與開發團隊解藕合的過程，讓 PO 去做最重要的事，才符合整個團隊的利益。下一篇文章，我們來聊聊 Refinement 的實踐方式，明天見！